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Description 

[0001J The present invention relates generally to creating software, and more particularly to aspecUoriented pro- 
gramming and aspect libraries. 

[0002] Procedural languages such as for Fortran. Pascal, and C are useful for defining programs where the execu- 
tion is straightforward, beginning at a starting point and executing in a stepwise manner to an end. In this model design 
issues can be addressed by units of contiguous program execution. Deviations from the straightforward path are pro- 
vided by function calls which allow program execution to jump from the main routine to the subroutine, and back again 
to the main routine. The use of subroutines allows for programming efficiency for implementing common routines-, how- 
ever, with programs becoming increasingly more complicated, and the number of common routines also growing pro- 
grams written in procedural languages are becoming increasingly complicated and difficult to maintain. 
[0003] With modem computer programs becoming increasingly long and complex creations which may have many 
millions of lines of code, the concept of modularity is becoming increasingly important in the development of software 
With a modular approach, the various functions of a computer program may be separated into modules which various 
programmers can work on independently. One popular programming paradigm that embodies the concept of modularity 
is that of object-oriented programming (OOP). 

[0004] The central idea behind object-oriented programming is the object model, where all programs are structured 
as collections of. interrelated objects, each of which represents an instance of some class in a hierarchy of object 
classes. 

[0005] Object-oriented programming involves defining, creating, using, and reusing "objects", which can be used to 
model ideas and things in terms of their features (data) and behaviors (methods). Each object is a self-contained soft- 
ware element including data and methods for operating on the data. Objects are created by defining object classes from 
which objects are created, or "instantiated". The object classes are templates for creating objects. Each object created 
from a particular object class includes all the data and methods of the object class, as well as data and methods from 
its superclasses, and different objects of lhe same object class may be used for different purposes. Common object- 
oriented programming languages include Smalltalk. C++, and Java. Object classes for implementing commonly- 
encountered issues are often packaged as class libraries which developers can call upon, rather than having to re-cre- 
ate new object classes. 

[0006] Other. non-OOP approaches are also commonly used, such as embodied in procedural programming lan- 
guages and functional programming languages. 

[0007] When design features may be cleanly divided among distinct elements, these approaches provide good 
support for programming those features in a modular way. However, these approaches fail to provide the proper support 
in certain situations, such as those involving shared resources, error handling, or other systemic issues where the same 
or similar functionality affects or is affected by many different elements. 

[0008] The reason why these approaches are insufficient is that those issues cross-cut the primary modularization 
of the systems. Cross-cutting occurs when some particular concern depends on and/or must affect parts of the imple- 
mentation of several of the functional modules of the system. Many cross-cuts are not weaknesses of the designs- they 
. are a natural and unavoidable phenomena in complex systems, and they are the basis for the concept of "aspect" 
[0009] Implementing those cross-cutting concerns in traditional programming languages, even object-oriented 
ones, typically requires scattering bits of code throughout the program, resulting in code that is tangled. 
[0010] For example, non-trivial performance optimizations tend to cross-cut many modules when writing programs 
using traditional programming languages. So, for example, using Lisp or Java, the implementation of a cross-cutting 
performance optimization ends up affecting the non-optimized, modular implementation of the components in ways that 
are all but obvious, resulting in code that is tangled and in loss of the optimization abstraction. 

[0011] In accordance with one aspect of the present invention, a computer system has a processor, a memory, and 
a software entity comprising either a program body or one or more object clasjses, the software entity defining an overall 
functionality of a software application program, and an aspect-oriented programming environment supporting an aspect 
that implements concerns that cross-cut the overall functionality of the software entity, the aspect comprising 

a) a cross-cut that comprises a point in the execution where cross-cutting behavior is to be included; and 

b) a cross-cut action comprising a piece of implementation associated with the cross-cut. the piece of implementa- 
tion comprising computer-executable code that implements the cross-cutting behavior; 

c) wherein the cross-cut action transparently forces the cross-cutting behavior on the software entity. 

[0012] An aspect is a concern that cross-cuts the primary modularization of a software system. An aspect-oriented 
programming language extends traditional programming languages with constructs for programming aspects. Such 
constructs can localize the implementation of cross-cutting concerns in a small number of special program modules 
rather than spreading the implementation of such concerns throughout the primary program modules. 
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[00131 ln o^er to capture the cross-cutting nature of aspects, such special program modules break the traditional 
rules of encapsulation in principled ways. They can affect the implementation of the primary modules without the explicit 
consent of those primary modules; further, they can do that for several primary modules simultaneously. 
[0014] Aspect oriented programing (AOP) extends the expressive facilities available to the programmer, so that 
many design decisions can be expressed locally. The AOP programmer writes the base program in a traditional pro- 
gramming language, and also writes pieces of aspect code, each of which affects executions that are described in some 
parts of the base program. 

[0015] In such a manner, aspect code can localize the implementation of some design patterns in a few modules, 
rather than spreading the fields and methods of those patterns throughout the classes, and can capture the tracing, 
debugging and instrumentation support for a complex system in a few modules, capture error handling protocols involv- 
ing several classes in a single module, and capture resource sharing algorithms involving several classes in a single 
module, rather than as multiple code fragments tangled throughout the classes. 

[0016] The special program modules for programming aspects enable this by cross-cutting the modularity of 
classes in principled ways. So one of those special program modules can affect the implementation of several classes 
(or several methods within a single class) in a clean, principled way. Aspect-Object interaction differs from Object- 
Object interaction and other traditional programming paradigms in that with the traditional approaches, all behaviors of 
the objects are encapsulated in the objects themselves, either as a direct implementation in the object class definition, 
as a request encoded in the object class definition to use the behaviors of other objects (e.g.. a method call), or as a 
request in the object class definition to reuse the implementations of other object classes (e.g. through inheritance). 
Thus, in these traditional approaches, all control of an object's behavior lies with the object itself. In the AOP environ- 
ment, on Ihe other hand, a part of the object's behavior can be defined in an aspect outside of the object without the 
object having to request the behavior in any way. Thus, it can be said that a part of the object's behavior is transparently 
forced on the object by the aspect. Moreover, aspects have a more global effect in that one aspect can forces its behav- 
ior on multiple objects, possibly of different classes. 

[0017] The paradigm of Aspect-Oriented Programming was first introduced in Gregor Kiczales et al.. Aspect-Ori- 
ented Programming in Proceedings of the European Conference on Object-Oriented Programming (SCOOP 97). June 
1997 ("Kiczales"). which is hereby incorporated by reference. In Kiczales, a new unit of software modularity, called an 
aspect, was provided that appears to provide a better handle on managing cross-cutting concerns. 
[00181 I" Kiczales. only highly domain-specific aspect-oriented systems had been developed. There was also a 
) goal of developing a general purpose AOP mechanism. At the time of the prior art. it was unknown how to generalize 
from the very specific examples of AOP to conceive of the necessary abstractions in order to create a general model. 
Thus, the aspect-oriented programming of the prior art was a hypothetical paradigm having the goal of providing a clean 
separation between and among components and aspects. 

[0019] In Kiczales. four highly domain-specific aspect-oriented systems had been developed. AML, RG. ETCML. 

s and D. For each of these cases, a new language had to be created, and a new compiler had to be implemented. While 
each of these languages included a notion of an "aspect", none of these aspects could be used with any of the lan- 
guages for the other three because the foundation principles underlying a general-purpose aspect language were not 
known. Thus, each time a new aspect-oriented application is to be created, a designer would first have to create a new 
language, and implement a new compiler before actually developing the software application. 

o [0020] The present invention presents a general-purpose aspect-oriented programming paradigm. The environ- 
ment embodying the present invention is called AspectJ, and avoids the shortcomings of prior art programming para- 
digms. AspectJ is an extension to the Java programming language. In AspectJ. object code is encapsulated in Java 
classes, and aspect code is encapsulated in special program modules called "aspects". 

[0021] The generalization embodied in the present invention is based on the realization that cross-cuts can be rep- 
's resented by capturing points in the computation, such as message sends, method definitions, object accesses, paths 
in sequences of calls, etc. > 

[00221 To improve the usefulness of aspects in simplifying software development, a library aspect is introduced 
which allows for the abstract implementation of AOP. 

50 Figure 1 illustrates an aspect according to an example of thethe present invention; 

Figure 2 is a flowchart depicting a method for creating a software program according to an example of the present 
invention; 

Figure 3 depicts an aspect libra.ry; and. 

Figure 4 is a block diagram of a computer system. 

[0023] In this example, the method is implemented on a computer system 400 (Figure 4) having a processor 410 
and a memory 420 including a software entity 430. 

[0024] The present invention is a system for facilitating the development of software programs using aspect-on- 
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ented techniques. In accordance with the present invention, the system of the present invention executes on a compu- 
ter, such as a general purpose personal computer of a type well-known in the art. 

[0025] Referring to Figure 1, an aspect 110 according to the present invention provides a general way of imple- 
menting cross-cutting behavior. To do so. the aspect includes a cross-cut 120 and a cross-cut action 130. These cross- 
s cuts can be concrete or abstract as will be described in greater detail in conjunction with the discussion of aspect librar- 
ies, below. The cross-cut includes points in the computation where the cross-cutting action is to occur. 
[0026] A point in the computation of a program is an action of the computation corresponding to a feature of the 
programming language in which the program is developed. 

[0027] Programming languages have features that describe kinds of actions to perform. A program written in the 
to programming language uses these features to call for specific such actions. When the program is executed, the imple- 
mentation dynamically carries out a sequence of these actions in accordance with the program's instructions. Those 
are referred to as points in the computation. 

[0028] Examples of points in the computation include reading a variable, a method invocation, the start of the exe- 
cution of a method, the return from a method invocation, instantiation of an object, test of a condition, the raising of an 

is exception, the capture of an exception, etc. 

[0029] Being able to refer to an intended set of points in the computation is a key technical requirement for having 
a general-purpose aspect language. But such a goal is not trivial to achieve, because many of those sets of points do 
' not have an explicit embodiment in the source code of the program. For example, objects are instantiated dynamically 
at run-time. Therefore denoting a method invocation on a specific object cannot be done through the use of a simple 

20 name, but must be done through denoting a variable that refers to that object and/or through enumerating properties of 
that object. 

[0030] A general-purpose aspect language provides support for identifying sets of points of interest in the compu- 
tation and for referring to them in the source code. By providing this support, the programmer can then associate one 
single piece of behavior with many different points in the computation. 
25 [0031] A cross-cut action is a piece of implementation (i.e., code) that is to be executed on a cross-cut. These 
cross-cut actions may be implemented using common programming techniques and common programming language 
constructs. 

[0032] Figure 2 illustrates the application, of AOP in developing and/or modifying software. AOP can be applied to 
any previously developed software application for which source code is available. This can be useful for applying such 
30 functionality as system monitoring or tracing, both of which are described in greater detail in our copending US patent 
application entitled ASPECT-ORIENTED SYSTEM MONITORING AND TRACING filed on 20 July 1 999, which is incor- 
porated by reference into the present specification. AOP can also be applied to previously developed software to add 
new functionality which cross-cuts the primary functionality of the software application. 

[0033] In developing new software, AOP can be used to software monitoring and tracing as described above, and 
35 can also be used to implement any other cross-cutting issues for the software application. A benefit of AOP is that the 
defining of aspects may be done concurrently with the development of the software entities defining the primary func- 
tionality of the software application. 

[0034] In either developing or modifying, primary functionality for the software is created as one or more object 
classes or other program bodies. Cross-cutting functionality is added to the software through the use of an aspect. 

40 Aspects implementing cross-cutting behavior are defined at step 210. Then, in order to have the aspects force their 
behavior on the object classes, the aspects are compiled, at step 220, along with the object classes. 
[0035] In a present embodiment bf the invention, a compiler for performing the compilation of step 220 takes the 
source files for the aspects and object classes, and produces intermediate object classes that are then compiled into 
byte codes. Those skilled in the art will readily appreciate that other ways of performing the compilation are possible 

45 without departing from the spirit of the invention. For example, the composition might be done at the byte code level. 
[0036] Tables 1 through 3, below, contain source code for an object clasi, and two aspect definitions, respectively. 
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File: Point. java 

import j ava . io . * ; 
import j ava . ut il . * ; 

class Point { 

private int _x = 0; 
private int _y = 0; 

Point () {} 

void set (int x, int y) { 
_x = x; _y = y; 



void setX (int x) ( _x = x,- 
void setY (int y) { _y = y; 



int getXO 
int getY() 



return _x; 
return _y; 



Table 1 -Source code for object class Point 



File: ShowAcces sea . java 



import j ava . io . * ; 

aspect ShowAccesses { 

public static void main (String {] args) { 
Point pi = new Point ( ) ; 
Point p2 = new Point ( ) ; 
Point p3 = new Point ( ) ; 



for (int i = 0; i <= 100; 
pl.set(i, i) 
p2.set(i, i) 
p3.set(i. i) 



advise Point(*), Line(*) { 
static before { 

System. out .println ( "C" ) ; 



) { 



} 



advise * Point .getX (*) , * Point . getY (*) , 
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* liine.getXl (*) , * Line .getYl (* ) , 

* Line .getX2 (*) , * Line .getY2 (* ) { 
static before { 

^ System. out .println ("R") ; 

advise * Point . set (*) , * Point . setX (*) , * 
Point. setY(*) , 

* Line. set (*), * Line . setXl (*) , * 
Line.setYK*) , 

* Line.setX2 (*) , * Line.setY2 (*) { 
static before { 

System. out .println ( »W" ) ; 



} 



} 



Table 2 - Source code for aspect ShowAccesses 



File: AutoReset . java 

import java.io.*; 

aspect AutoReset { 

public static void main (String [ ] args) 
Point pi = new Point (); 
Point p2 .= new Point () ; 
Point p3 = new Point (); 

AutoReset al = new AutoReset ( ) ; 
al.addObject (pi) 
al.addObject (p2> ; 
al.addObject (p3) ; 



for (int i = 0; 
pi. set (i, i),- 
p2.set (i, i) ; 
p3.set(i, i); 



i <= 100; i+ 



Point. sfeltX(. .) , 



int count = 0 ; 
advise * Point . set ( . 
Point. setY (, .) { 
after { 

if (++count >= 100) { 

System. out .println ( "Reseting " 
thisObject + " . " ) ; 

count = - 1 ; 
x = Q; 
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1Z_— — J 

U Table 3 - Source code for aspect AutoReset 



--- File: a j workmgdirXPomt . j ava -- 



import java.io.*; 
import java.util-*; 

class Point extends j ava . lang . Object { 
int _x = 0; 
int _y = 0 

Point 0 { 

} 

' * This method contains the original method 
body for 

* void set (int x, int y) 

* This method is called from the original 
method. 

protected final void Point$set ( int x, int y) { 
_X = X ; f . . 

_y = y; 

} 
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-p - — 

* The body of this member was replaced by 
aspect j 

* At the core of this code is a call to 

* protected final void Point$set (int x, int y) 

* which holds the original method body. 

* Around this call is the code for all advise 

* weaves that apply to this member. 
*/ 

void set (int x, int y) { 
{ 

/* 

* Generated by aspect j 

* This implements the before advice * 

set() ' 

* weave from the aspect ShowAccesses . 
( ShowAccesseB . j ava : 2 7) 

*/ . 

{ 

- j ava. lang. System. out .print In ("W« ) ; 
} . 

Point $set (x, y) ; 

/*- 

* Generated by aspectj 

* This implements the after advice * set() 

* weave from the aspect AutoReset . 
(AutoReset. j ava :24) 

. */ 
{ 

java.util. Enumeration _enumeration = 
_aspects . elements ( ) ; 

while ( enumeration. hasMoreElementsO ) { 
j ava . lang .Object _thisAspect = 
_enumeration. nextElement () ; 

if (_thisAspect instanceof AutoReset) 

{ 

final AutoReset thisAspect = 
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fAutoReeet ) _thisAspecu .- 

if (++thisAspect. count 100) { 
java.lang.System.out.printlnC'Reseting - + this 



thisAspect .count = -1; 
_x = 0; 
_y = 0; 

} 

} 

} 

} 

.} 

} 

} 

1 * This method contains the original method 
body for 

* void setX(int x) 

* This method is called from the original 
method. 

* / 

protected final void Point$setX (int x) { 
_x = x,- 

) 

'\ The body of this member was replaced by 
aspect j 

* At the core of this code ib >a call to 

* protected final void Point$setX (int x) 

* which holds the original method body. 

* Around this call is the code for all advi 

* weaves that apply to this member. 
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void setX(int x) { — 

I 

/* 

* Generated by aspect j 

* This implements the before advice * 

setXO 

* weave from the aspect ShowAccesseB . 
(ShowAccesses . java : 27 ) 

. */ 
{ 

java. lang. System. out. println ("W" ) ; 

} . 

Point$setX (x) ; 
/* 

* Generated by aspect j 

.* This implements the after advice * 

setXO 

* weave from the aspect AutoReset . 
( AutoReset . j ava : 2 4 ) 

*/ 

java. util .Enumeration _enumeration = 
_aspect s. elements () ; 

while (_enumeration.hasMoreElements () > { 
java . lang. Object thisAspect = 
_enumeration.nextElement () ; 

- if (_thisAspect instanceof AutoReset) 

{ 

final AutoReset thisAspect = 
(AutoReset ) _thisAspect ; 
{ 

if (++thisAspect.coun^ >= 100) { 
java. lang. System. out. println ("Reseting " + this + 

"."); 

thisAspect. count = -1; 

X = 0; 
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} 

} 

} 

} 

} 

} 

} 

' * This method contains the original method 
body for 

* void setYtint y) 

* This method is called from the original 
method . 

*/ 

protected final void Point$setY ( int y) { 

_y = y; 

} 



* The body of this member was replaced by 
aspect j 

* At the core of this code is a call to 

* protected final void Point$setY (int y) 

* which holds the original method body. 

* Around this call is the code for all advise 

* weaves that apply to this member. 
*/ 

void setYtint y) { _. 

{ 

/* \ 

* Generated by aspect j 

* This implements the before advice * 

setYO 

* weave from the aspect ShowAccesses . 

I (ShowAcceases.java-.27) . . 
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{ 

j ava . lang . System . out . println ["VI") ; 

} 

Point$setY(y) ; 
/* 

* Generated by aspectj 

* This implements the after advice * 

sety ( ) 

* weave from the aspect AutoReset . 
( AutoReset . j ava -. 24 ) 

*/ 

- { 

* j ava !util .Enumeration _enumeration = 
aspects . elements ( ) ; 

while (_enumerat ion . hasMoreElemente () ) { 
j ava. lang. Object _thisAspect = 
_enumeration.nextElement () ; 

if <_thisAspect instanceof AutoReset) 

{ 

- final AutoReset thisAspect = 
(AutoReset ) _thisAspect ; 

- { 

if (++thisAspect . count >= 100) { 



java. lang. System, out. println ( "Reseting " + this + 

thisAspect . count = -1; 
_x = 0; 

• _y = 0; 

} 

} 

} 

} 

) 

) 
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* This method contains the original method 
body for 

* int getxO 

* This method is called from the original 
method. 

protected final int Point$getX() { 
return _x; 

) 

/* 

* The body of this member was replaced by 
aspectj 

* At the core of this code is a call to 

* protected final int Point$getX() 

* which holds the original method body. 

* Around this call is the code for all advise 

* weaves that apply to this member. 
*/ 

int getXO { 

int thisResult; 
{ 

/* 

* Generated by aspectj 

* This implements the before advice * 

getX ( ) 

* weave from the aspect ShowAccesses . 
(ShowAccesses. java-.20) 

*/ 

{ *> 

java . lang . System. out . print In ( "R" ) ; 

} 

thisResult = Point$getX() ; 

> 

return thisResult; . 
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} 

/* 

* This method contains the original method 
body for 

* int getY() 

* This method is called from the original 
method . 

*/ 

protected final int Point$getY() { 
return _y; 

} 

/*.. 

* The body of this member was replaced by 
aspect j 

* At the core of this code is a call to 

* protected final int Point$getY() 

* which holds the original method body. 

* Around this call is the code for all advise 

* weaves that apply to this member. 
*/ 

int getYO [ 

int thisResult; 

{ . 

/* 

* Generated by aspectj 

* . This implements the before advice * 

getYO 

* weave from the aspect ShowAccesses . 
(ShowAccesses . java:20) 

*/ \ 

{ 

j ava. lang . System. out . print In ( "R" ) ; 

} 

thisResult = Point$getY() ; 
} ; 
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return thisResult; 

} 

protected java.util .Vector .aspects = new 
java.util. Vector () ; 

public java.util. Vector getAspectsO { 
return _aspects; 

} 



Table 4 



r intermediat e code tor object class 



File: aD workingdir\sh owAccesses. 3 ava 



import java.io.*; 

class ShowAccesses extends java. lang. Object ..{. 
public static void main (java. lang. String [] 

args) ( 

Point pi = new Point (); 
Point p2 = new Point (); 
Point p3 = new Point (); 
for (int i = 0; i <= 100; 
pi .set (i, i) ; 
p2.set(i, i) 
p3.set(i, i) 



{ 



•able 5 - Intermediate code 



aspect ShowAccesses 
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File: a j worki ngdi r \ Aut oRe se t . j ava 



import java.io.*,- 

class AutoReset extends j ava. lang. Object { 

public static void main<j ava . lang . String [] 
args) { 

Point pi = new Point ( ) ; 

Point p2 = new Point ( ) ; 

Point p3 = new Point () ; 

AutoReset al = new AutoReset () ; 

al.addObject (pi) ; 

al .addObject (p2) ; 

al.addObject (p3) ; 

for (int i = 0; i <= 100; i++) { 
pi. set (i. i) ; 
p2.set(i. i) ; 
p3.set(i, i) ; 

} 

) 

int count = 0; 

private j ava . util .Vector objects = new 
j ava. util. Vector () ; 

public j ava. util .Vector getObjectsO { 
return _objectB; 

} 

public void addObject (Point object) { 
if ( !_objects .contains (object) ) { 

object.getAspectsO .addElement (this) ; 
_objects .addElement (object) ; 

} 

} 

public void removeObject (Point object) { 
object.getAspectsO . removeElement (this) - 
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^_obj ects . removeEieraent (.otrj ect ) ; 

} 



'- Table 6 - intermediate code for aBpect AutoKeaet 

stand the transformations necessary for ,mplement.ng a compiler according p 
Aspect Libraries 

(0039, Withtheincreasingcomp.^^ 

software programs require a vast number of elemen *Man of ^J™'^^ the sa me software pro- 
interfaces, and those addressing "^^^^SlS^-n issue reappears, a genera, routine for 
gram, and for other programs. Rather than creating * sof(ware entity , which may b e one or more pro- 

implementing the solution may be accessed ,. m hbrary T ^^ a functjona(ity ^ software program will include 
gram bodies or one or more ob]ect classes, embodying tne P" m ^ gre , ar res0 urces for 

calls to a library routine. In ob i ect ^ riented P r ° 9 ^^ writing code for new issues rather 

developing software applications ^^"^^^^^^^ ^velopers in other applications, 
than having to re-create solutons that ^^%^ n ^^Zg a nU mber of library aspects 312. Library 
[00401 Referring to Figure 3. an aspect library 310 ,s shown ndudmg ^ ^ jp ^ 1 

aspects may be concrete or abstract. A concrete libr^y »^££££*us* a I the cross-cuts in it refer to con- 
only packaged as part of an aspect library. It ,s ««-^ "^JJJS in object classes. In a present embod- 
creL points in the computa^ 

imen. of the invention, the concrete aspect extends he ^™ ™ a " a ** of tne l vention . 

implementing this extension can be practiced without deparUng from the sp, nt o ^ ^ ^ thejr 

t 0O P 41, The power of an aspect .ibrary es ir ^^^^'^-on. An exemplary abstract library 
implementations can be reused or several dtferen se s of pom . P ^ ^ )jbrary aspect 

aspect 315 includes crosscut acbons as .n aspect 1 10 if F.gure i . ou i 

Si as a placeholder rather than being specified as a IJ^^^^^h^^^of -n«*^ 
[0042] When use of an abstract library aspect is dewed .A is £" nd 1° '° , ne P deve , oper . ln , he concrete aspect, 
not shown) created from object class 320 ""^J*^ ^esj the cross-cuts 317 in the library aspect 
the developer uses the crosscut to define bindings 335 between tne name 
<o 315 to concrete points in the execution 325 of the object i compilation of abstract cross-cuts 
[00431 In a present embodiment of the .nvention. acomp "^Jjlm h ana V«>ncrete and abstract library 

of Java's byte code format, e.g.. tags concrete aspecl and an object 

[00441 Tables 7 through 9 contain source code for an abstract uorary «>v 
class, respectively. 
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MethodDebug. java 

aspect MethodDebug { 

abstract crosscut debugTypes; 

crosscut allMethods: * *(..) on ©debugTypes ; 

static advise ©allMethods ( . . ) { 
before { 

System, out. println ("about to call 
"+thisJoinPoint . methodName ) ; 
} 

after { : 

System. out . println ( "have called 
" +this JoinPoint . methodName+ 

" , returns 

"+thisResultObject) ; 

} 

} 

Table 7 - source code for abstract library aspect 
MethodDebug 



aspect DebugMyClass extends MethodDebug { 

crosscut debugTypes: on MyClass ; 

} ; . 

Table 8 - Source code for concrete aspect DebugMyClass 



class MyClass { ~ ~ 

public void method () { 

System . out . println ( "MyClass " ) ; 

public void bar(int x) f 
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- system-out. println("bar( »+x+") on MyCTilFTi 



Table 9 - Source code f or object class MyCia3B 



: a jworkingdir\MethodDebug.java 



class MethodDebug extends j ava . lang . Obj ect { 




a jworkingdir\DebugMyClassoava 



class DebugMyClass extends MethodDebug { 



} 

Table 11 - intermedia te code tor object cxa'ss 
DebugMyClass 



. ajworkingdir\Myuiass. 3 *i 



class MyClass extends j ava. lang. Obj ect { 
^protected final void M y Class$method$signature ( )_ 
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1 

j ava . lang . System . out . print In ( "MyClass" ) ; 

) 

public void method ( ) { 
{ 

/* 

* Generated by aspect j 

* This implements the before advice * *(> 

* weave from the aspect MethodDebug. 
(LibTest. j ava: 13) 

*/ 

■ ( . 

j ava . lang . System . out . print In ( " about to 
call " -i- "method"); 

} " 

MyClass$method$signature() ; 
/* 

*. Generated by aspect j 

* This implements the after advice * *() 

* weave from the aspect MethodDebug. 
(LibTest. j ava: 16) 

*/ 

{ 

java. lang. System. out . print In ( "have called 
" + "method" + " , returns " + 
( (java. lang. Object) null) ) ; 
} 

) 

} 

protected final void MyClass$bar£s > ignature (int 
x) { 

java. lang. System, out. println( "bar (" + x + ") 
on MyClass") ; 
} 
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public void bar(int x) { 
{ 

/* 

* Generated by aspect! 

* This implements the before advxce 0 

* weave from the aspect MethodDebug . 
(LibTest. java:13) 

*/ 

( ja va.lan g .System.out.println(»about to 

call " + "bar") ; 
} 



M yClass$bar$signature (x) ; 



/ * i 

* Generated by aspect] 

* This implements the after advice O 

* weave fro, the aspect MethodDebug. 
(LibTest. java: 16) 

*/ 

{ ja va.lang.System.out.println("have called 

.. + -bar" + " . returns " + 
(( java. lang. Object) null)) ; 



> . .. „„ r .^ e ~forlob"ject class MyClass 

Table 12 - intermediate code tor ^ j 



m „™ and a software entity comprising either 



i program body or one 
i program, and 
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an aspect-oriented programming environment supporting an aspect that implements concerns that cross-cut the 
overall functionality of the software entity, the aspect comprising: 

a) a cross-cut that comprises a point in the execution where cross-cutting behavior is to be included: and 

b) a cross-cut action comprising a piece of implementation associated with the cross-cut, the piece of imple- 
mentation comprising computer-executable code that implements the cross-cutting behavior; 

c) wherein the cross-cut action transparently forces the cross-cutting behavior on the software entity. 

2. A system according to claim 1 . wherein the cross-cut defines a plurality of points in the computation associated with 
a plurality of places in the software entity. 

3. A method for developing software in a computer system including an aspect-oriented programming environment 
supporting an aspect that implements concerns that cross-cut the overall functionality of the software entity the 
method comprising: 

a) creating a software entity comprising either a program body or one or more object classes, the software 
entity defining an overall functionality of a software application program, 

b) creating an aspect which modifies at least one software entity by forcing behavior on the al least one soft- 
ware entity, wherein the modification is transparent to the at least one software entity; 

c) compiling the software entity along with the aspect to thereby force the behavior of the aspect onto the soft- 
ware entity. 

4. The method of claim 3, wherein the cross-cut defines a plurality of points in the computation associated with a plu- 
rality of places in the software entity. 

5. The method of claim 3 or claim 4; wherein creating an aspect comprises: 



Jt defining a point in the computation where cross-cutting behavior is to be included; and 
Jt action comprising a piece of implementation associated with the cross-cut, the piece of 
implementation comprising computer-executable code that implements the cross-cutting behavior. 

The method of any of claims 3 to 5, wherein the cross-cut is a concrete cross-cut that uniquely defines a point in 
the computation where cross-cutting behavior is to be included. 

The method of any of claims 3 to 6, wherein the computer system further includes an aspect library including a 
library aspect, the method comprising creating the cross-cut comprises creating a concrete aspect that reuses 
parts of an implementation of the library aspect. 

An aspect library for use in a computer system having a processor, memory, and an aspect-oriented operating envi- 
ronment, the aspect library for use in creating a software program, the software program comprising one or more 
software entities that define the overall functionality of the software program, each of the one or more software enti- 
ties comprising one or more program bodies or one or more object classes, each of the one or more software enti- 
ties comprising computer executable code which performs one or more functions, the aspect library comprising a 
plurality of aspects, each aspect comprising: 

a) a placeholder for specifying a cross-cut that comprises a point in the execution where cross-cutting behavior 
is to be included; and 



it action comprising a piece of implementation associated with the cross-cut, the piece of imple- 
mentation comprising computer-executable code that implements the cross-cutting behavior; 
c) wherein the cross-cut action transparently forces the cross-cutting behavior on the software entity. 

A computer-readable medium for use a computer system having a processor, a display, and memory, the memory 
including an aspect-oriented operating environment, the computer-readable medium having an aspect library com- 
prising a plurality of aspects, each aspect comprising: 

a) a placeholder for specifying a crass-cut that comprises a point in the execution where cross-cutting behavior 
is to be included; and 

b) a cross-cut action comprising a piece of implementation associated with the cross-cut. the piece of imple- 
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. wo mde that implements the cross-cutting behavior; 
mentation comprising computer-executab le » cross . cutting behavior on the software entity, 

c) wherein the cross-cut action transparently forces 

nrnduct from one or more first computers to a second computer con- 
A method for transferring a computer program i product . medjum , he metnod comprising: 

nected to the one or more first computers through a commun ca 

ore first computers an aspect library comprising a plurality of aspects, each 
a) accessing, on the one or more first computers, 
aspect comprising: 

„ . * • — « — - ■ - * ~ *- 

behavior is to be included: and irnp , e mentation associated with the cross-cut the piece of 

2) a cross-cut action compns.ng a p.ece^ o i imp imp , em ents the cross-cutting behav.or; 
implementation comprising ^^^^^^ bM °" M * 

3) wherein the cross-cut act.on transparently forces 

, „, .ho nnp or more first computers to the second com- 
b) transferring the computer-executable instruct.ons from the one 

puter. 
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